QuickDraw has always been able to deal with color, just on a very limited basis. Most applications have not made use of this feature, since Color QuickDraw-based Macintoshes come with a better color model. There are, however, a few nice features which come with the old style color model. With the old style colors, it is easy to print color on an ImageWriter with a color ribbon. Another advantage is that developers do not have to write special-case code depending upon whether or not a machine has Color QuickDraw.
Now that you are ready to convert to the old style colors, there are a few things you should know about which do not work with old style colors. This Note covers the limitations of using old style colors, as well as the best ways to work around these limitations.
Limitations
The most obvious limitation is that of only eight colors: black, white, red, green, blue, cyan, yellow, and magenta. This limitation is only a problem if you want to produce a color-intensive application; if this describes your application, then you need not read any further in this Note.
The next limitation is that off-screen buffers are not very useful. You can draw into off-screen buffers, but there is no way to get the colors back from the buffer. This leads into the next limitation, which is that _CopyBits cannot copy more than one color at a time.
When you call _CopyBits from an off-screen buffer to your window, you need to set the forecolor to the color you want to copy before calling _CopyBits (i.e., to copy a red object, call _ForeColor(redColor)). Now when you copy the object, you can only copy one color. If you copy different colored objects at one time, then you have a problem. The result of a multicolored copy is that all objects copy in the same color, that of the foreground.
It is possible to work with an off-screen buffer and the old style colors, but it requires a lot of extra work. Unless the objects are really complex, then it is probably easier to just draw the objects directly into your window.
One other limitation does exist. Consider the following code sample. One would assume that this sample would work at all times.
SetPort (myPort);
savedFG := myPort^.fgColor;
ForeColor (redColor); {or any other color}
{...drawing takes place here...}
ForeColor (savedFG);
Surprise. It doesnΓÇÖt always work. The saved value for the fgColor field of the grafPort is not a classic QuickDraw color if the grafPort is actually a CGrafPort. If dealing with a CGrafPort, the fgColor field actually contains the foreground colorΓÇÖs entry in the color table, so the second call to
_ForeColor really messes things up.
The proper way to set and reset the foreground color with classic QuickDrawΓÇÖs
_ForeColor call is as follows:
SetPort (myPort);
savedFG := myPort^.fgColor;
ForeColor (redColor); {or any other color}
{...drawing takes place here...}
myPort^.fgColor := savedFG; {manually stuff the old fgColor back}
If (32BQD = TRUE) Then
PortChanged (myPort);
This Note also applies to the routine _BackColor.
What Works
The easiest way to work with these limited colors is to use pictures. When you draw the images, you should draw into a picture. Then when you want to draw the images into your window or to a printer, call _DrawPicture. Pictures work well with the old style colors, and you donΓÇÖt need to worry about making sure that the forecolor is current when you draw into your window.
Once you have the picture, you can use it to draw into the screen or to the printer port. You can also set the WindowRecords windowPic to equal your PictureHandle so updates are handled by the Window Manager.
